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I . INTRODUCTION 



A. NAVAL AIR REWORK FACILITY, NORTH ISLAND 

The Naval Air Rework Facility (NAVAIREWORKFAC) , North 
Island Naval Air Station, San Diego, California, is the 
largest of six naval air rework facilities presently 
operated by the United States Navy, to service aircraft 
of the United States Navy and Marine Corps. The facility 
is an industrial activity of the naval shore establishment, 
under the command and primary support of the Commander, 

Naval Air Systems Command. Command, management coordina- 
tion and technical control has been delegated to the 
Assistant Commander for Logistics/Fleet Support, Naval Air 
Systems Command, who exercises this responsibility through 
the NAVAIRSYSCOMREPAC. The Commanding Officer, NAVAIREWORKFAC, 
is held accountable for the efficiency, effectiveness of 
performance, and economy of operations and prescribes vital 
management systems and standards within which local manage- 
ment structure and systems will be developed. The 
NAVAIREWORKFAC is under Navy Industrial Funding. 

The workload of the NAVAIREWORKFAC includes a complete 
range of rework and engineering operations on designated 
weapons such as aircraft, engines, components and associated 
accessories and equipments. Aircraft serviced by the 
NAVAIREWORKFAC include the F-4, E-2 and helicopters. The 
rework performed on these aircraft includes repair, overhaul, 
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conversion, modernization, progressive aircraft rework 
and analytical rework as well as repair of crash damage 
when feasible. In addition, the NAVAIREWORKFAC , North 
Island, has been tasked with Project Bee-Line--the con- 
version of F-4 B's to F-^-N's. 

The NAVAIREWORKFAC is presently made up nine major 
divisions (Figure 1), and employs over 7 ,000 personnel. 

Each division is made up of a direct labor force and an 
indirect labor force which is composed on managerial, 
secretarial, supervisory and administrative personnel. 

The NAVAIREWORKFAC has an annual budget of $165 million 
and overhauls approximately 80 aircraft and 23 >000 re- 
lated components per quarter. 

The Production Engineering Department, 60000, (Figure 2), 
as one of the sxaff elements of the NAVAIREWORKFAC, pro- 
vides functions that are essential to the operations of 
the other departments of the Activity. The timely exe- 
cution of these functions require close relationships 
within the Production Engineering Department as well as 
with the Production Planning and Control and Aeronautical 
Engineering Departments. The Production Engineering 
Department acts upon current and short-range planned pro- 
duction information from the Production Planning and 
Control Department and longer-range planned production 
information from the Naval Air Systems Command. 

The Operations Analysis Division, 6 2000 , initiates 
the production engineering of these programs, and develops 
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and implements the operations analysis program covering 
the production shop operations. The Operations Analysis 
Division is composed of three branches: Accessories and 

Components Branch, 62100; Aircraft and Engines Branch, 

62200; Pilot Overhaul Branch, 62300 . The data furnished 
by the Operations Analysis (62000) and by the Methods 
and Standards (63000) Divisions are the basic tools for 
the Production Planning and Production Control Divisions 
of the Production Planning and Control Department in 
carrying out their respective functions. 

B. DEFINITION OF PROBLEM 

An orderly induction and flow of work through the 
NAVAIREWORKFAC is assured by detailed Workload Control 
procedures. A management information system, NAILC/MIS 
Stage I , provides information retrieval to the operational 
level. That portion of the NAILC/MIS which is the responsi- 
bility of the NAVAIREWORKFAC is known as the Workload 
Control Segment. The Workload Control Segment provides 
the means to retrieve information from the production 
shops and to process the data with certain source documents 
to create required management reports . The various master 
data files required to support this management information 
systems are primarily maintained by the Operational Analy- 
sis Division. The Operations Analysis Division also 
researches and develops the technical data for the pre- 
paration and maintenance of the Master Data Records (MDR) 
on all rework programs . 



12 



The MDR is the primary source of data for the pre- 
paration of production control documentation and subsequent 
management reports. The MDR file must be created and 
maintained properly before any of the other NAILC/MIS 
applications can be successfully operational. The MDR 
is a dynamic Master File which requires timely and accurate 
file maintenance to insure that production control and 
management reports contain the latest information. 

The NA VAIREWORKFAC has a master data file of approxi- 
mately 159 ,000 MDRS as of the end of 19?^. These MDRs 
are the responsibility of the three branches of the 
Operations Analysis Division with the Components Branch, 
62100, responsible for approximately 75 percent of the 
existing MDRs. The daily MDR file maintenance required 
is becoming an increasingly greater part of the Operations 
Analysis Division’s workload. The Components Branch also 
has the responsibility of routing other branch MDR inputs 
and maintains the Optical Character Recognization (OCR) 
typist pool for the division (with the exception of two 
OCR typists in the 62200 Branch) . The daily file mainte- 
nance consists of update actions resulting from changes 
to time standards, codes, processes, routings, technical 
directives, deletion of MDRs for components no longer 
processed and the addition of new MDRs. 

The master data file is on magnetic tape storage 
in a computer, but the file maintenance is accomplished 
by manual means such as hand-written forms, the guard 
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mail and OCR typists to produce an OCR input to be read 
by an OCR scanner. The OCR scanner transfers the MDR 
update information to magnetic tape for batch updating 
the master data file at a later time. Essentially, the 
present manual file maintenance process results in time 
delays which average five to seven days to update an MDR. 

In addition, priority items, heavier than usual workload 
for the analysts and OCR typists and human factors fre- 
quently produce backlogs which can result in time delays 
much greater than for routine changes. 

C. PURPOSE AND OBJECTIVES 

Early in 1973 NAVAIREWORKFAC recognized the problems 
inherent in the manual maintenance system used for the 
MDR master file, and a need to upgrade the present method 
of file maintenance was clearly established. Code 210 
was directed to begin a detailed study of the potential 
for random access (on-line) updating of MDRs via remoted 
terminals connected directly to a computer. Meetings 
with Data Processing Services Center Pacific resulted in 
a proposed on-line system utilizing the Burroughs 4700 
computer via remoted CRT terminals and remoted printers. 
NAVAIREWORKFAC and Code 210 personnel have pursued the 
project with hopeful implementation of system on 15 
September 1974. However, personnel equipment and mone- 
tary restraints have precluded meeting the September date. 

As of January, 1975s a user "Synopsis of System Requirements" 
has been compiled to be forwarded to the NAILC/MIS MDR 
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Program Manager as the NAVAIREWORKFAC , NORIS , requirements 
for On-Line MDR Maintenance. In addition, system speci- 
fications are being prepared to forward to the Data 
Processing Service Center, Pacific, (DPSCPAC) and 
Workload Control Team; the specifications are expected 
to be completed by 15 March, 1975* 

The purpose of the work presented in this paper is to 
study the present MDR file maintenance system and report 
on the system, how it operates and problem areas en- 
countered. Several problems which exist in the present 
system, along with possible methods for remedying the 
problems will be described. The MDR On-Line Project 
presently being pursued by the NAVAIREWORKFAC will be 
discussed and critiqued, and several recommendations for 
further study presented. 
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II. PRESENT MDR FILE MAINTENANCE 



A. MASTER DATA RECORD 
1 . Definition 

The MDR is the primary source document for pro- 
duction control documentation and subsequent management 
reports . At the end of 1974 NAVAIREWORKFAC maintained 
an MDR Master File composed of approximately 159 » 000 
separate documents . The MDR Master File is stored on 
magnetic tape in a Univac 3301 computer system; the master 
file is interfaced with other computer routines of the 
NAILC/MIS system to. produce various reports, some auto- 
matically and others on request. A hard copy (shown in 
Figure 3) of each individual MDR is filed in tub- type bins 
located in the branch of the Operations Analysis Division 
responsible for that type of MDR. Accessories and the 
Components Branch, 62100, has responsibility for approxi- 
mately 123,000 MDRs; the Aircraft and Engines Branch, 
62200, approximately 24,000 MDRs; and the Pilot Overhaul 
Branch, 62300, approximately 11,000 MDRs. 

Four basic types of MDRs are used. The Routing 
Master Data Record (RMDR) details the routing through 
the various feeder shops for processing of components. 

The components may be units removed from an aircraft 
or engine, inducted for repair and return items through 
the Component Program, Recall Calibration items, Plant 
Equipment Calibrated on site, etc. Items removed for 



16 



MASTER DATA RECORD 
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Figure 3* Master Data Record 



accessability from an aircraft or engine or items removed 
and routed to the finished parts storeroom with no inter- 
mediate processing also utilize the RMDR. 

The Operational Master Data Record (OMDR) is 
developed for operations to be performed on the basic 
aircraft or engine. These operations include disassembly, 
assembly, work performed on the airframe or engine, paint- 
ing, flight testing, etc. The Progressing Master Data 
Record (PMDR) is prepared for each Type/Model of aircraft 
or engine. The primary purpose of PMDRs is to report 
status in accordance with locally assigned check points 
as the units progress through the rework cycle. The Pilot 
Overhaul MDR is developed for the purpose of establishing 
production capability for assigned aircraft, engines and 
components . 

2 . Data Elements 

The data elements contained in the MDR are divided 
into five major data groups. The data groups are further 
divided into three types of fields. Key Fields: data 

fields that are necessary for the record to be of use 
in subsequent computer processing. The key fields include 
the MDR Control Code (MDRCC) , Component Identity Code (CIN) , 
MDR Location, Change Code and the Shop Category Code. 

The MDR will be printed on an error listing if these 
fields are invalid. Optional (uncontrolled) Fields: 
informational fields which are not critical to the use 
of the MDR and may be left blank or used as defined. 
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Mandatory (controlled) Fields: specific purpose fields 

in which the data is mandatory. If the data are erroneous 
in either the optional or mandatory fields, it will be 
overlaid with equal signs and an appropriate error code 
assigned to the MDR. 

The fields within the Control Group control the 
sequence of MDR placement in the master file and serve as 
identification data. The Control Group is composed of 
the following: MDRCC , CIN, source code, error code and 

change code. The MDRCC identifies the major work program; 
Family Identification Code (FIC) for the component program; 
and the schedule frequency and week number for the Recall 
Calibration and Preventative Maintenance programs. The 
CIN identifies eacii routing identity within an MDRCC. 

The Fart Identification Group contains 24 data 
fields. These fields contain data for part identification 
purposes and miscellaneous codes for controlling preparation 
of operating documents and summarized workload information. 
The Load and Schedule Group contain data elements required 
to schedule and control the movement of parts through 
the process cycle. The Miscellaneous Information Group 
contains the MDR Location Code and five lines for entering 
special instructions or any type of information that can- 
not be entered elsewhere on the MDR. The Technical Data 
Group has spacing available for listing a maximum of 40 
technical directives relating to the routing identity. 



19 



B. USE OF MDR 



The MDR is an essential part of the documentation 
system that ensures a timely and orderly flow of work 
through the NAVAIREWORKFAC . The data elements contained 
in the MDR are used to prepare Shop Orders, Job Cards 
and Work-In-Progress (WIP) records which are processed 
through subsequent computer routines to provide data 
for planning, scheduling, workload history, cost account- 
ing , operating reports and reports to higher commands . 
Figure 4 is the typical documentation flow for the Standard 
Depot Level Maintenance Program for aircraft. 

When an aircraft is scheduled for induction to the 
NAVAIREWORKFAC, the master data file (refer to Figure 3) 
is inquired by aircraft type and bureau number for all 
documentation pertainent to that specific aircraft. The 
computer produces an aircraft file on magnetic tape from 
the master file that has all the documentation required 
for rework of that aircraft, and automatically sends 
documentation to the Examination and Evaluation Branch 
of the Production Planning and Control Department. When 
examination and evaluation of the aircraft is completed, 
the individual aircraft file is inquired for the docu- 
mentation necessary to direct and monitor the rework 
cycle on that aircraft. 

In addition to reports generated automatically or upon 
request that provide data to the NAVAIREWORKFAC management, 
reports are produced that support the MDR master file 
and reflect the results of MDR maintenance actions. 
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Figure 4. Standard Depot Level Maintenance 




These reports tabulate erroneous data submitted and re- 
jected, undesirable conditions within the master file 
and information extracted from the master file. Table I 
is a listing of the automatically produced reports that 
support the MDR file maintenance process. 

C. MAINTENANCE OF MDR FILE 
1 . General 

Information retrieval from the MDR master file 
in the form of managerial reports and workload documenta- 
tion effects the entire operation of the NAVAIREWORKFAC . 
The MDR file must be created and maintained properly 
before any of the other NAILC/MIS Workload Control appli- 
cations can be successfully operational. The importance 
of timely and accurate file maintenance cannot be over- 
emphasized. The MDR master file maintenance is a daily 
routine which involves deletion of obsolete and addition 
of new MDRs and correction or updating of other MDRs. 

The Operations Analysis Division is responsible 
for the submission and validity of the Master Data 
Record Worksheet, the Master Data Record Changes and 
the MDR Control Group Changes and Additions forms . These 
forms are used to create and maintain the MDR file. The 
Quality Assurance and Reliability Department, Methods and 
Standards Division and the Production Planning Division 
supply required supporting MDR maintenance data to the 
Operations Analysis Division via the Master Data Record 
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Produced Automatically (Ref. 2) 



Changes and the MDR Workload Control Form. The Operations 
Analysis Division is responsible for the physical mainte- 
nance of the "hard copy" printed MDRs. These MDRs are 
available to the Methods and Standards Division, the 
Quality Assurance Division and any other organizational 
unit authorized by the Operations Analysis Division. 

Sample copies of the Master Data Record Worksheet and 
the Master Data Record Changes Form are shown in Figures 
5a and b and 6a and b . 

2 . New MDR 

The creation of a new MDR is initiated by dis- 
tributing seven numbered computer punch cards , known 
as the "seven card deck," to organization units within 
the NAVAIREWORKFAC for the purpose of developing inputs 
to a new MDR. The Components Branch, OA-621, has control 
of the process if it is a production MDR; The Pilot 
Overhaul Branch, OA-623, if it is a pilot MDR. The number 
six card signals the OA-621 branch to begin research for 
a new components MDR. An analyst is assigned to the MDR 
and begins the Master Data Record Worksheet. The work- 
sheet is sent to the various branches for required data 
inputs and the OA-623 branch establishes the rework 
capability. When OA-623 has established rework capability 
and all inputs to the MDR Worksheet have been received 
by OA-621, the cognizant analyst will forward the work- 
sheet to the OCR typist to be converted to OCR input 
form and forwarded to DPSCPAC. Figure 7 depicts the 
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Figure 5a. Master Data Record Worksheet, Front Side 



MISCELLANEOUS INFORMATION GROuR 




26 



Figure 5t>* Master Data Record Worksheet, Back Side 
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Figure 6a. Master Data Record Change Form, Front Side 
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Figure 6b. Master Data Record Change Form, Back Side 
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Figure 7« Establishment of Component MDR 



documentation flow for the establishment of a new MDR. 

The maintenance of the existing MDR file is a 
daily routine consisting of updating and correcting. the 
data presented on an MDR. Update actions result from 
changes to time standards, codes, processes, routines 
and technical directives originating from either within 
the NAVAIREWORKFAC or outside agencies. The primary 
change form used is the Master Data Record Changes. The 
Master Data Record Control Group Changes and Additions 
form is used to effect changes in the MDRCC and CIN fields 
in the MDR control group. The preparation of the desired 
change or update to an MDR is accomplished using manual 
methods — handwritten forms and the guard mail. The 
change is input to the computer via an OCR scanner which 
transfers the information to magnetic tape for later 
batch updating of the master file. 

3 . Existing MDR 

The MDR change process is initiated in OA-621 
with the receipt of a "request for service" from anyone 
of the organizational units in the NAVAIREWORKFAC. The 
major inputs to OA-621 come from Quality Assurance 
Department, 40000, Methods and Standards Division, 63000, 
Production Planning Division, 52000, Technical Services 
Division, 35000, and the Production Department, 90000. 

The "request for service" can be in the form of a memo- 
randum, partially completed MDR change form, MDR change 
Directive form or verbally by phone. Once the change 
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request is received by OA-621 an analyst is assigned by 
the supervisor of the pertinent section within OA-621 
which has responsibility for the particular MDR. The 
analyst retrieves the existing MDR from a storage bin 
to complete the necessary research and paperwork to effect 
the requested change. The analyst completes the MDR 
change form and forwards it to the supervisor of the 
OCR typist pool. 

The MDR change form is checked for completeness 
and accuracy prior to being assigned to a typist for 
conversion to the OCR format necessary for computer input. 
The typed OCR sheet is again checked for accuracy and 
cleanliness prior to being sent to DPSCPAC for processing. 
At 1500 each day the OCR sheets completed that day are 
sent to DPSCPAC to be read by a scanner which stores the 
data on magnetic tape. At 0400 each morning DPSCPAC 
runs a batch update of the MDR master file using the 
data stored on tape from the scanner. 

The batching process sequences the MDR change 
data to create new MDRs and change or delete existing 
MDRs in the master file. The MDR file maintenance 
routine edits, validates and reformates the change data 
to produce a change file for MDR update . An updated 
MDR file is produced and MDR update reports are gen- 
erated along with printouts of revised and new MDRs 
(see Table I) . 
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The OCR sheets are returned to the OCR typists 
supervisor at 0800 the day following submission along 
with a diagnostic sheet produced by the OCR scanner 
which prints out OCR errors by page number and line 
number on the OCR sheet; a red dot is placed to the left 
of any OCR line that was incorrect. The OCR typists 
review and correct any OCR lines that are rejected by 
the scanner validation routine. The data is retyped and 
submitted again to the scanner. The printouts of the 
revised and new MDRs are received by the OCR typists 
between 0800 and 1400 of the day following submission 
of the change. The MDRs are compared against the MDR 
change forms for correctness and then forwarded to the 
responsible analyst for filing. 

Figure 8 depicts the data flow process for an 
MDR change that originated in the Methods and Standards 
Division, 63000 . Data supporting the time delays in- 
volved is given in Appendix A. The physical separation 
of the Methods and Standards Divisions from OA-621 
necessitates hand- carrying, via the guard mail, of all 
paper work. Some of the MDR changes desired by the 
Methods and Standards Division require the use of the 
existing MDR printout, in which case the MDR has to be 
requested from OA-621. This procedure normally adds 
one or two days or more to the process of initiating the 
desired change if requested MDR is unavailable. 
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Figure 8. Methods & Standards MDR Update Flow Chart 



All component MDR changes desired by Methods and 
Standards Division have to be routed through OA-621 with 
the exception of time standards of common operations. 

These time standards are identified by an Operation Code, 
MSCC, which is unique to that operation. These changes 
are forwarded to the Management Methods Division, 21000, 
where they are converted to OCR format and sent to the 
DPSCPAC. All other component MDR changes are put on indi- 
vidual MDR change forms and forwarded to OA-621. All MDR 
changes have to be reviewed by the responsible analyst 
in OA-621. The analyst checks the change against the 
existing MDR for proper fields, codes, etc. and enters 
line number of change. The standard procedure is for the 
analyst to take this opportunity to review the existing 
MDR for any other required changes. The analyst then for- 
wards the completed MDR change form to the OCR typists. 

The average time involved for the MDR change form 
to leave the Methods and Standards Division, be processed 
by the analyst and arrive at the OCR typist supervisor's 
desk is 1.54 days with a standard deviation of 1.6? days. 
If one allows one-half day for the guard mail this implies 
that the MDR change form is in the analyst’s possession 
for one day. The average time the MDR change form is at 
the OCR typist pool prior to being forwarded to DPSCPAC 
is 3«08 days with a standard deviation of 1.52 days. 
Assuming the OCR scanner at DPSCPAC does not reject the 
data input and adding one day for the MDR master file 
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update, the time lapse for an MDR to be updated is 5-6 
days if no errors are made during the process. 

The processing of the MDR change through the. OCR 
typist pool to DPS CPA C and back to the OCR typist pool 
is as described earlier. The hard copy of the revised 
MDR is forwarded to the analyst to be filed. However, 
the Methods and Standards Division does not receive any 
feedback from OA-621 as to the status of the MDR change. 
The feedback to the Methods and Standards Division comes 
through indirect means and ax a time weeks after the 
actual MDR change has been affected. The feedback can 
be in the form of a computer generated report on MDR file 
status (see Table I) , or a review of the MDR when a second 
change is necessary. Standard operating procedure is for 
the Methods and Standards Division to review an MDR for 
accuracy and completeness each time it comes through the 
office for one reason or another. 
k . MDR Maintenance Workload 

The Accessories and Components Eranch, OA--621, 
employs 2? analysts. An analyst is assigned to one of 
three different sections within OA-621: Aircraft section, 

F/j section and Process section. One of the analysts 
assigned to each section is also the supervisor for that 
section. The branch employs six typists who make up the 
OCR typist pool, one of the six is also the supervisor. 

In addition, two secretaries/clerks are employed: one 

for the Operations Analysis Division and one for OA-621. 
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The OA-621 MDR file maintenance workload is com- 



prised of updating and deletions of existing MDRs and 
the creation of new MDRs for aircraft related components. 

The workload can he further divided into four basic cate- 
gories: research work for development of new MDRs; research 

work for update and change of existing MDRs; clerical 
work-filing, completing MDR change forms, etc; and clerical 
work for other branch and division MDR inputs for which 
OA-621 does not have change authority but does have routing 
authority. The last category is becoming an increasingly 
greater part of the workload for OA-621 analysts. 

Data that was gathered from the records kept by 
OA-621 personnel is summerized in Table II. The number 
for revision of existing MDRs includes inputs from other 
divisions such as Methods and Standards for which OA-621 
has routing responsibility. Approximately ten percent of 
the total MDRs typed were inputs to the OCR typists from 
the Pilot Overhaul Branch, OA-623. Data gathered through 
interviews with OA-621 analysts indicate that actual MDR 
file maintenance comprises approximately 84 percent of 
their workload (data supporting this number given in 
Appendix A). The workload is augumented by special pro- 
jects such as a recent changeover from Federal Stock 
Numbers to the new National Stock Number system and the 
projected introduction of the phased maintenance system. 

The workload is not evenly distributed between 
the three sections of OA-621 and varies from day to day 
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Operation 


July 


Aug. 


Sept. 


Total 
for 
Qtr . 


Total 

for 

1974 


New MDRs Written 


1249 


334 


896 


2479 


12479 


Revise Existing MDRs 


17673 


30829 


20790 


69292 


239622 


MDRs from OA-623 








57 17 


28757 


MDRs Typed (OCR) 


23143 


28808 


25537 


77488 


280858 


Lines Typed (OCR) 


78220 


75853 


67467 


221540 


860192 



Table II. OA-621 MDR Workload First Qtr FY'75 

within each section and within the branch. The uneven nature 
of the workload necessitates the analyst spending a great 
deal of time performing clerical duties such as filing when 
the time could be better spent in research. The overall 
workload of the OA-621 branch is slowly increasing to the 
point where the analysts cannot perform their other 
responsibilities . 

The workload of the OCR Typist Pool is divided be- 
tween converting data from a source document to an OCR 
format and proofreading of OCR prepared documents against 
source documents. Proofreading of OCR documents rejected 
by the OCR scanner is required because of poor alignment 
of typing on the form, typing across field boundaries, 
uneven typing, poor spacing, spots on form, etc. In addi- 
tion, the OCR typist compares the computer printout of the 
updated MDR against the MDR change form for completeness 
and accuracy prior to forwarding the MDR to the responsible 
analyst. • 
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The volume of OCR lines typed daily varies greatly. 
The time that an MDR form is in the OCR typist pool prior 
to being typed ranges from one to eight days. Work is 
backlogged at the OCR typist for several reasons: for 

example fluctuations in workload and priority system. 

Table II gives the total number of OCR lines typed by the 
pool during the first quarter of FY' 75 and the entire 
calendar year, 1974. 
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III. PROBLEMS AND SOLUTIONS 



A. GENERAL 

1. Errors 

The problem areas encountered in the present manual 
system of maintaining the MDR file have to be examined from 
two viewpoints: for example from the viewpoint of the 

user, the Components Planning Branch, 52300 > and from the 
viewpoint of the MDR producer. The MDR is actually a 
"basic work plan" for an aircraft or an aircraft related 
component and its effectiveness cannot be known until 
long after its contents have been incorporated into firm 
plans , actions and commitments of the NAVAIREWORKFAC units 
and rework has begun. Therefore the importance of accuracy 
and completeness of both the development of new MDRs and 
the maintenance of existing MDRs cannot be overemphasized. 
There are three basic types of errors that can occur in 
the MDR file maintenance process: analyst’s errors, typo- 

graphical errors that are not discovered, and typographical 
errors that are discovered and corrected prior to being 
read into the computer. 

The analyst deals with two basic concepts: data 

and information. Data are raw facts in isolation which, 
when placed in a meaningful context by some process, allow 
interferences to be drawn. An unlimited amount of data 
is available from sources both internal and external to 
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the organization, but not all data produce relevant and 
timely information. Information is the aggregation or 
processing of data to provide knowledge or intelligence. 

The analyst has to gather data through his research and 
convert the data to some form of useful information. 

Errors made at this stage either through gathering in- 
accurate data or using the wrong data to produce erroneous 
information are not detectable until some later date when 
the MDR is actually put to use. The ability to detect 
this type of error is independent of the system, manual 
or computerized, used to process and store the information 
and the MDR master file. 

The second type of error to be considered is the 
typographical error (in the case of the MDR maintenance 
process, an OCR typographical error) that is subsequently 
discovered and rectified prior to being input to the up- 
date tape. The error can be discovered during the proof- 
reading process by the typists or it can be discovered 
and rejected by the OCR scanner at DPSCPAC. The OCR 
scanner contains a debug routine which will detect and 
reject lines of input that are not correctly formatted, 
contain dirt spots, entries outside the field length, etc. 
The result on the MDR maintenance process is identical 
v/hether the error is detected by the typist or the OCR 
scanner — increased delay time in the update procedure. 

A line rejected by the scanner, verified and corrected 
by the OCR typist, adds at least one day (and usually more) 
to the time required to update that MDR. 
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The third type of error is the typographical 
error that goes undetected and is allowed to pass into 
the MDR master file. This type of error has the same 
result as the analyst's error--long term effects. The 
mistake is not picked up until the MDR is used in some 
other unit of the NAVAIREWORKFAC; and, then it may be 
used several times before the mistake is noticed. Once 
the error is detected, the entire update process is 
again initiated and the overall result is double the nor- 
mal amount of time delay and paperwork to get the correct 
MDR in the master file. 

2 . Timeliness 

The value of information is based on several 
attributes; of interest here is timeliness and accuracy. 
Timeliness is related to a shorter elapsed time of the 
update process input, processing and output to the users 
for the MDR file. The normal situation is that for infor- 
mation to be timely, the elapsed time from input to 
output must be reduced. Timeliness is difficult to 
measure, but its effects can be seen. For example, the 
Components Planning Branch, 52300, makes inquiries to 
the MDR master file each weekend; therefore as long as 
the MDR master file update process has a time delay less 
than a week, the information is timely for this user. 
However, for a user, such as the Aircraft Examination 
and Evaluation Branch, 52600 , which may make inquiries 
daily, a week time delay for changes and corrections to 
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an MDR is certainly not timely. The MDR master file is 
presently updated daily, but the frequency of updates 
does not imply how timely is the information. The 
important factor is the time delay from input to output 
within the system. 

3 . Ac curacy 

Accuracy pertains to the degree of freedom from 
error of input and output of the master file. When dealing 
with large volumes of data and information, two types of 
mistakes usually occur: errors of transcription and 

errors of computation. These errors have already been 
discussed. For the MDR to be of practical use, it must 
be accurate by the above definition; it must also be com- 
prehensive. Comprehensive refers to the completeness of 
the information presented on the MDR; it does not mean 
volume but rather the inclusive aspect of the information. 
Naturally one desires as accurate a system as possible, 
but accuracy costs time (as well as money) . 

The present system has several points where ac- 
curacy of the input is checked for accuracy and content. 

The Operations Analysis' analysts check all inputs for 
which they have routing responsibility; for example, inputs 
from the Methods and Standards Division. These inputs are 
checked for content, correct line number, proper entries 
to a given field, etc. Once the analyst has completed 
an MDR change form, it is forwarded to the OCR typists 
where it is again checked. It is the responsibility of 
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the OCR typist to call to the attention of the supervisor 
any random or systematic errors appearing in the source 
documents. Once typed, the OCR sheet is proofread against 
the source document prior to being forwarded to the com- 
puter center for input to the OCR scanner. The OCR scanner 
contains a debug routine that checks input data and accepts 
or rejects data line by line. One mistake in a line rejects 
the entire line ; in some cases an error in a line can also 
cause the rejection of several succeeding lines. The 
scanner routine prints out an error sheet listing the 
rejects by page and line number which is returned to the 
OCR typists along with the OCR sheets the following morning. 
The MDR master file batch update routine contains several 
stages of verification which input data has to go through 
prior to the file actually being updated. Input data which 
does not meet the verification process is rejected and 
the computer prints out an error listing. The error list- 
ing is returned to the OCR typists along with printouts 
of the updated MDRs. The OCR typists verify the updated 
MDRs by comparison with the source documents prior to 
forwarding the updated MDRs to the analysts for filing. 

The present MDR update process contains six levels of 
error verification, both manual and computerised. The 
OCR typists spend approximately 50 percent of their 
time performing the verification function. 

The accuracy problem is compounded by the manner 
in which some branches obtain the MDR derived documents. 
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MDR derived documents are obtained by submitting document 
request forms to the computer center. The computer prints 
out all documents requested once a day. It is the practice 
of several branches to order more than one set of documents 
at a time if a need for the documents will arise sometime 
in the near future . Therefore if the MDR master file is 
incorrect or in the process of being updated several sets 
of incorrect documents will be used rather than just one 
set of incorrect documents. 

If the concepts of timeliness and accuracy of data 
and information and frequency of updating the master file 
are considered collectively, certain conclusions can be 
drawn. The time duration between successive updates 
of the master file has no effect on the timeliness of the 
information provided the time between updates is shorter 
than the time elapsed during the update cycle. It is also 
clear that the more timely information is , then the more 
relaxed the standards for accuracy of the information can 
be. Feedback from the output to the input is a necessary 
element of the cycle. The value of timeliness and accuracy 
is greatly diminished without feedback. 

One theme that was present in most of the inter- 
views conducted at the NAVAIREWORKFAC was a lack of 
feedback concerning the MDR maintenance process. This 
was particularly true for the users of the MDR and its 
derived documents such as the shop order card. Specific 
examples are the Methods and Standards Branch and the 
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Aircraft Examination and Evaluation Branch. Some indi- 
viduals felt that they had no way of knowing what 
happened to an MDR change request once it had been sub- 
mitted. In most cases, some sort of feedback system was 
provided for, but it was used infrequently if at all. 

B. EXAMPLES 

1. Accessories and Components Branch 

The responsibility for file maintenance and 
storage of approximately 123,000 MDR documents results 
in a heavy workload being placed on the branch staff and 
tends to prevent the staff from effectively completing 
other duties not related to MDR file maintenance. The 
problem is aggravated by the oscillating nature of the 
workload both for the branch as a whole and in individual 
sections of the branch. Additional factors which tend 
to contribute to the heavy workload are incorrect inputs 
to OA-621 from other branches and divisions; other branches 
and divisions making changes and updates to MDRs that are not 
authorized for that branch; and the human factor — penman- 
ship and handwriting. Unauthorized changes are made to 
the MDR either by mistake, perhaps due to a lack of under- 
standing of the MDR, and purposely in an attempt to speed 
things or beat the system. 

Some of the problems resulting from the heavy MDR 
workload are MDR hard copy filing and storage, tedious 
and repetitive paperwork, a large volume of OCR conversion 



(discussed in following section) , and huge backlogs of 
routine changes accumulating due to "one time only" mass 
changes and priority assignments to change requests. As 
a result of the oscillating workload, analysts are pre- 
sently rotated from section to section within the branch 
to cover backlogs and unexpected increases in the workload. 
In addition, the analysts assist the OCR typists in their 
filing and clerical duties and in verification if the 
typist pool becomes more than four days backlogged. One 
of the general results of the heavy workload and its 
accompanying problems is to introduce an appreciable time 
delay in the MDR update and change process. Interviews 
with staff members of affected branches establish this 
time delay to be in a range of three days to a month or 
more depending on the scope and priority of the change or 
update. The routine changes are the most likely to be 
delayed long periods of time as they are backlogged due 
to the priority system. 

The MDR hard copy storage and usage contributes 
considerably to the overall problem. Only one hard copy 
of each MDR is produced by the computer and the storage 
of it is the responsibility of the cognizant branch of 
the Operations Analysis Division. The single copy is 
used by all branches of the NAVAIREWORKFAC . This intro- 
duces the additional problem of keeping track of the MDR's 
location when a branch other than the responsible branch 
has possession of it. (Some aspects of this problem are 
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discussed in following sections.) The MDR Routing/Control 
Sheet, Figure 9» initiated by Code 621 (26 September, 197*0 
represents an attempt to control the MDR document more 
closely, but also represents additional paperwork. The 
MDR hard copy documents are stored in moveable tub-type 
bins at different locations in the components branch, 
normally in close proximity to the analysts' desk who are 
concerned with them. Due to the large number of documents, 
considerable space and time are consumed in storage and 
filing activities by the staff of the branch. 

The Accessories and Components Branch maintains 
an OCR typist pool consisting of six typists, one of which 
is the supervisor. These typists handle the input from 
OA-621, OA-623 and all inputs for which OA-621 has routing 
and verification responsibility. The present workload 
is, on the average, within the capabilities of the typist 
pool. As expected occasional bottlenecks and slack periods 
do occur; however, the slack periods are disappearing and 
the workload is steadily increasing. 

The purpose of OCR is to decrease the computer 
input bottleneck by reducing the number of keying opera- 
tions and errors in transcription. Ideally, the OCR 
scanner equipment will read any document and transmit 
the data to the storage tape. However, increased sensi- 
tivity to document conditions (such as smudges, creased 
documents, dirt and poor quality paper) can cause many reject 
The scanner contains a debug routine which will reject 
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Figure 9* MDR Routing/Control Sheet 
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lines of input for certain errors in the input data also. 
The rejection rate of the OCR Scanner due to the above 
factors is one percent or less of the submitted data. 
However, the verification and correction process for 
this error rate plus the verification time involved in 
checking the updated MDRs against source documents con- 
sumes approximately 50 percent of the OCR typists' daily 
workload . 

There are several contributing factors to the 
problems encountered in the OCR typist pool. A high 
turnover rate for the typists due to a lack of advancement 
opportunities and job oversimplication leads to a low 
experience level within the typist pool and aggravates 
the oscillatory nature of the workload. The necessity 
for absolutely clean OCR documents requires special hand- 
ling of the OCR sheets. Manual retrieval of source 
documents to implement corrections and verify errors adds 
to the clerical filing duties of the OCR typists. 

2 . Methods and Standards Division 

The MDR maintenance that the Methods and Standards 
Division has responsibility for is the updating and ac- 
curacy of time standards on the MDR. About 60 percent 

of the affected MDR lines fall into an operational coded 

\ 

category and can be changed or updated by a mass change 
procedure which does not involve the Operational Analysis 
Division nor does it require Methods and Standards 
Division to use a copy of the MDR to affect the change. 
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However, not necessarily 60 percent of the MDR related 
workload is concerned with this type of change. The 
remaining portion of the MDR workload may or may not 
require a copy of the MDR document, but it is required 
to be routed through either OA-621 or OA-622. If a hard 
copy of an MDR is required, the document must be requested 
from the cognizant custodian. If OA-622 has custody of 
the desired document the time delay is minimal because 
of the close proximity of Methods and Standards Division 
to OA-622. If the MDR document is held by OA-621 or OA-622 
a request sheet has to be sent either through the guard 
mail or hand-carried to obtain the specific MDR desired. 
This method can take as long as three days; if the MDR 
desired is not available for any reason, such as it being 
in a current change status or being used by another branch, 
the delay could be longer. This problem is greatly 
aggravated by the large number of existing MDRs in the 
file and the physical separation of the branches requiring 
the use of the hard copy MDRs . 

3 . Communications Section, Avionics Division 

The feeder shops in the Production Division use 
the MDR derived shop order card. Each piece of equipment 
that arrives in a shop is accompanied by a shop order card 
that lists routing, time standards operational information, 
etc. The card also contains listings of technical direc- 
tives and local engineering specifications (LESs) . It is 
important that the shops have accurate and up-to-date 
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information pertaining to technical directives and LESs . 

At the present time a shop bench technician checks all 
incoming components and shop order cards for correct 
and complete listings of technical directives and LESs 
pertaining to the specific pieces of equipment. The 
listings are checked against the technicians knowledge 
of the equipment and shop maintained files. If incorrect, 
changes to the existing shop order card or an entirely 
new shop order card have to be handwritten by the techni- 
cian. This process is costly both in manhours and 
paperwork and, in addition, increases the turn-around 
time of the component in the shop. 

The shop supervisor is required to fill out and 
send a Request for Service form to the Operations Analysis 
Division when a shop order card is found to be incorrect. 
Considerable time can be consumed during the MDR change 
process since analysts and possibly the technical direc- 
tives branch research the change to insure that it is 
the correct change required. During this period of time 
work in the shop is proceeding based on the hand-written 
changes made by the shop technician which could possibly 
be found to be incorrect by the analysts. 

4 . Aircraft Examination and Evaluation Branch 

The Aircraft Examination and Evaluation Branch 
primarily uses the shop order card which is derived from 
the MDR. Important information provided by the shop 
order card is shop routing for various components removed 
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from aircraft undergoing rework and listings of applicable 
technical directives. Both accuracy and completeness of 
this information are important. The Aircraft Examination 
and Evaluation Branch is divided into eight units, each 
with several people hand tailoring shop order cards either 
to correct errors or take into consideration special 
handling of components off a specific aircraft. The large 
volume of cards and componenets being handled by these 
units allows the possibility of errors being introduced 
to the system, as well as errors being discovered and 
corrected. If inaccurate or, in the case of technical 
directives, incomplete information is detected, the pre- 
printed shop order cards provided by the computer are 
hand edited and used until a correction can be made to 
the MDR. If the pre-printed documents are completely 
wrong, a Document Request Card (DCR) is used to request 
new pre-printed documents. Sometimes as many as three 
or four aircraft may be affected before the MDR and sub- 
sequently the shop order cards are corrected for missing 
technical directives and LESs. Any error on DCR form 
entries or errors made by the OCR typist results in 
the non-receipt of documents and further time delays. 

The following example from a memorandum dated 4 November, 
1974, demonstrates the time delays frequently encountered. 

On 1? October 1974, a DRC Form was initiated to process 
22 each assemblies (using Document Request Code "1") on 
Sequence BX 44, an ACE aircraft. On 22 October 1974, an 
error sheet was received which showed a wrong job order. 
Job order "0XT3444" was annotated vice "jZfXT3444." (It 
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may be noted that the Aircraft Program Schedule Sheet #X-50, 
the Work Jacket for Sequence BX44, and reference (a) are 
all incorrect in that they shew the Aircraft Program as 
"0" vice ” 0 " ) . On 22 October 1974, the DRC form was 
resubmitted for the second time. Evidently, the OCR typist 
dropped the digit "2" in the "day" column. The next error 
sheet was received on 24 October 1974, by Code 21210, for 
the third time. On 2 5 October 1974, we received the cards 
requested with the exception of two sets of sub-assembly 
documents. Code 21210 was contacted on 25 October 1974, 
who in turn initiated a DRC form for those components for 
the fourth time. As of this data, 4 November 1974, the 
documentation has not yet been received. Meanwhile, we 
have initiated HWSD's, handwritten shop orders, for those 
components and have sent them to their respective feeder 
shops. (Ref. 3-) 

The problem concerning technical directives and 
LESs in the Aircraft Examination and Evaluation Branch 
appears to be similar to the problem concerning LESs 
in the feeder shops in that both situations lead to the 
necessity of hand-tailored shop order cards. In the case 
of the LESs at the shop technician level, all of the shop 
order cards are checked very carefully against shop records 
and directives and the technician's experience. The value 
of the shop order card seems to vary with the experience 
level of the technician. There also appears to be a lack 
of confidence in the information provided to the technician 
by the shop order card. During the examination and evalu- 
ation phase, the shop order cards are not so carefully 
checked, and a mistake may go undetected until the com- 
ponent is further into the rework cycle. The important 
point here is completeness of the technical directive and 
component routing information provided by the shop order 
card . 
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C. ALTERNATIVES 



1 . General 

There are several alternative schemes that can be 
followed that would alleviate or, hopefully, cure some of 
the problems besetting the present MDR file maintenance 
process. The ideal solution is one which would improve 
the efficiency of the MDR file maintenance process, and 
at the same time, reduce the costs encountered in MDR file 
maintenance. Any course of action will require commitment 
of some level of resources and will produce some level of 
effectiveness. In choosing an alternative, an organization 
may take one of two approaches: (1) commit the necessary 

resources to obtain a specified level of effectiveness; 
or (2) for a specified level of resources design a system 
to produce the highest possible level of efficiency. 
Ideally, there exists some optimum balance between the 
two approaches; that is, there is some point where further 
efficiency is insignificant when compared to the added 
cost. The following list of alternatives is presented 
in a hierarchy of effectiveness from lowest to highest 
without regard to cost. Each alternative will be briefly 
discussed and some advantages and disadvantages will be 
presented. 

2 . Additional Manpower 

Hiring an additional file clerk or an OCR typist 
would definitely increase the output of the OCR typists 
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and reduce the present backlog problem. However, in- 
creased OCR capacity does not cure the problem, it merely 
eases the problem for a time. Adding more analysts to 
the staff would also reduce backlog and perhaps decrease 
the MDR update cycle time. Addition of a file clerk 
would reduce the clerical work performed by analysts at 
the present time and allow them to give more time to their 
assigned duties. More personnel increase the training 
and employee turnover problems while doing little to ease 
the problems of MDR hard copy storage, high paperwork 
volume and MDR update cycle time . 

3 . Modification of MDR Document Storage 

The present, centralized storage method for the 
MDR documents gives rise to three problems: space, filing 

time and time delays in distributing the documents to 
users other than the custodians . Each Branch that uses 
the MDRs could maintain its own file of MDR documents to 
ease the distribution problem. The major disadvantages 
of maintaining several separate files is the large size 
of the files. 

Computer Output Microfilm (COM) provides a medium 
other than paper for storing large amounts of information. 
The output of the computer is directly to a microfilm 
recorder which is connected to a film developer. The 
final output is in either roll film or microfilm form 
and can be viewed directly through special CRT type 
readers. Major advantages of COM are: (1.) Microfilm 
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is rugged and long lasting, it does not require extensive 
insulation from possible damage from environmental con- 
ditions such as radiation, heat and humidity. (2.) The 
need for storage space is greatly reduced. (3«) It is 
relatively inexpensive. Disadvantages of COM are; (1.) 

It is a poor application for large files which require 
updating. (2.) Requires special microfilm reading devices. 
(3-) Search and file methods must be performed by hand 
(Ref. 4) . 

4. Data Input Systems 

The preparation of data for computer processing 
is a significant bottleneck in any system. In the MDR 
file maintenance cycle the OCR typist is the interface 
between the manual portion of the system and the comput- 
erized portion of the system and, as such, controls the 
throughput of the entire system. A punched card system 
will not be considered because the present OCR system is 
faster and more efficient. A large portion of the OCR 
typists' time is consumed in verifying and correcting 
OCR scanner rejections against source documents. By re- 
ducing the volume of data rejection by the computer, the 
throughput of the system could be greatly increased. 

Keying data directly onto a storage medium other than the 
OCR input format would also remove the OCR scanner from 
the da.ta input process. 

The key-to-disk methods involve keying data 
directly onto magnetic tape or a magnetic disk. A typical 
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system consists of a low-cost minicomputer; direct access 
intermediate storage, usually magnetic disk; and magnetic 
tape for final output. Several keyboards will usually 
share the centralized minicomputer and storage device. 
Complex data pooling, formating and entering fixed data 
fields automatically are possible with this type of system. 
The keyboard, either CRT or teletypewriter, provides 
visual verification of the input data being keyed to the 
storage medium. A debug program, such as the present 
routine incorporated in the DPSCPAC OCR scanner, could be 
resident in the minicomputer to detect operator errors 
and provide immediate error correction. The final output 
of such a system would be a reel of magnetic tape which 
could be sent to DPSCPAC to be direct input to the com- 
puter for the batch update process. 

The advantages of this type of system ares 

(1) Elimination of the OCR to magnetic tape 
conversion. 

(2) Input data editing, formatting and verifi- 
cation functions handled automatically by the minicomputer. 

(3) Reduction in time lag encountered in error 
verification in present OCR systems. 

The major disadvantages of the key-to-storage method is 
that the source document still must be manually keyed; 
only the storage medium has been replaced. Data pre- 
paration, speeds and error rates are still dictated by 
operator efficiency (Ref. 5)* 
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5* On-Line Retrieval 



An on-line information retrieval system is one in 
which a user can directly search a master data file stored 
in a computer. The system is essentially a one-way com- 
munication device between the user and a computer. The 
input device can be a simple keyboard or a more sophisti- 
cated device such as a teletypewriter or CRT display 
terminal. The input device is tied to the computer via 
trunk lines or a regular telephone line. In the computer 
the data base is stored either on magnetic tape or magnetic 
disk in such a manner that allows the computer to search 
the data base for requested information. The output device 
can be either the teletypewriter , CRT terminal or a high 
speed printer. One high speed printer can handle the 
output from several input terminals. 

The major advantage of an on-line, retrieval-only 
system to the Operations Analysis Division is the elimi- 
nation of the MDR printed copy storage and filing require- 
ment. Placing terminals and a printer in each of the 
divisions who have a requirement for printed MDRs would 
also reduce the problem encountered in the present 
centralized MDR storage system. The decrease in the 
amount of time spent in. filing activities would allow 
the analyst to spend more time at his primary duties. 

Major disadvantages of the system are: (1) OCR 
typists still required to enter data into the system; and, 
hence, the system would not reduce the error rate or time 
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delay attributable to the OCR typists, and (2) the amount 
of paperwork is not diminished. 

6. On-Line Retrieval and Update 

The system required for on-line retrieval and 
update is composed of the same basic equipment as a system 
for retrieval only. However, the system is now a two-way 
communication device between the user and the computer. 

The system operates in a time-sharing mode which gives 
the user the illusion that he is the sole user of the 
computer when, in reality, the computer is being shared 
among a number of independent activities and users. The 
system can be either a real-time or delayed-time system. 

A real-time retrieval system responds so rapidly to a 
query that its response may be regarded as immediate or 
quick enough to be utilized in the continuation of the 
task being conducted. The update process can also operate 
in either a real-time or delayed-time mode. In a real-time 
operation, the master file is continuously updated as an 
analyst communicates with the computer via a terminal. 

In delayed-time operation, update instructions and data 
are input to the computer via the terminal and stored 
on magnetic tape or a magnetic disk temporary storage 
medium. At some later time, the accumulated data is 
batch processed and the MDR master file is updated in the 
same fashion as the present system. 

The major advantages of this system compared with 
the present MDR maintenance system are: 
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(1) Elimination of the OCR typists and the OCR 
format to magnetic tape conversion process. 

(2) Elimination of the MDR printed copy storage 
and filing requirement. 

(3) Immediate feedback to the analysts concerning 
input data errors . 

(4) Reduction in the amount of paperwork required 
of the analysts. 

(5) A reduction in the elapsed time for an MDR 
to be updated. 

Disadvantages associated with the on-line file 
maintenance systems are of two types s those associated 
with the introduction of the system and those of a con- 
tinuing nature. The major problem encountered during 
introduction of the system is the change-over from the 
old to the new system. The analysts have to be trained 
to operate the terminals or new personnel have to be 
acquired as operators. Disadvantages of a continuing 
nature are : 

(1) File security. 

(2) System downtime. 

(3) One or two OCR typists have to be retained to 
handle unexpected workload or to handle workload during 
extended downtime of the computer. 

(4) Source documents still must be keyed into 
the computer. 

(5) Practically everyone understands the present 

system. 
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7. New System 



Three alternatives always exist when a system and 
a set of user requirements are evaluated: (1) to do 

nothing, (2) to modify an existing system and (3) to 
design a new system. The alternatives discussed previously 
modify the existing system in an attempt to more effectively 
satisfy the MDR file maintenance requirements . The final 
alternative available is to design a new system; this last 
alternative is obviously the most complex and difficult 
solution to implement. The present MDR file maintenance 
system is interfaced with the NAILC/MIS system and any 
redesign of the present MDR maintenance systems would 
affect the entire NAILC/MIS system. However, the present 
MDR may not be adaptable to any of the alternatives dis- 
cussed above. The most cost-effective solution may be to 
completely redesign the MDR and at the same time design 
a computerized file maintenance system. 
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IV. NAVAIREWORKFAC ON-LINE PROJECT 



A. GENERAL 

The. ON-LINE PROJECT at NAVAIREWORKFAC was initiated 
in 1973 with the primary purpose being to eliminate the 
delay and uncertainty of batch process update of the MDR 
master file. The final form of the proposed system, 

Figure 10, is to use a randomly accessed master file and 
real-time update to give immediate validation of updates 
and changes and a continuously current MDR file. An 
auxiliary purpose was to affect cost savings, time savings 
and space savings by eliminating most of the bulky, man- 
ually maintained desk files. The project began with a 
rather ambitious and optimistic time schedule which was 
immediately beset with money and people restraints and, 
perhaps, somewhat of a lack of interest on the part of 
the management. At the present time, the implementation 
date for the full system has slipped by at least a year 
with the full system operation date currently set for 
February, 1976. It is hoped to have a prototype system 
installed and operating in OA-621 by the end of November, 

1975. 

Work on the project has proceeded in three areas: 

(1) Design of several formats to display portions of 
the MDR on a CRT. (2) Development of the specifications 
and procedures that define how the user and DPSCPAC 
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Figure 10. Proposed NAVA IREWORKF AC On-Line System 



interact with the system. (3) Specifications to develop 
the software necessary to process the data and perform 
the MDR file maintenance function (completed on 15 March 
1975) • (4) System user requirements were compiled 

(Appendix B) . In addition, the project personnel have 
made field trips to the U.S. Army Tank and Automotive 
Command, Warren, Michigan and Rohr Data Systems, Chula 
Vista, California to familiarise themselves with on-line 
file maintenance and communication systems. Several vendors 
have also heen contacted to gain information on equipment 
required for such a system. User requirements, management 
specifications and system specifications will he forwarded 
to DPSCPAC who will write the software programs . 

Planning conferences between DPSCPAC and Code 210 
personnel have produced a proposed on-line system. DPSCPAC 
computer facilities consist of two Univac 3301 systems, 
one Burroughs 4500 and one Burroughs 4700 system plus 
several smaller computers and peripheral equipment. The 
proposed system, Figure 10, would use the Burroughs 4700 
computer plus additional equipment that would have to be 
acquired: communication lines, CRT terminals, auxiliary 

storage units and a minicomputer front-end processor for 
the Burroughs Computer. The proposed prototype system 
is consisted of five terminals, four in 0A-621 and one 
at DPSCPAC plus an off-line printer in OA-621. The pro- 
posed CRT terminal has capability of displaying 11 lines 
that are maximum of 80 characters in length. 
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The present MDR master file contains 159>000 records, 
v/ith a maximum length of 4100 characters . The file is 
a part of the NAILC/MIS system, on magnetic tape, and 
run on a Uni vac 3301 computer system. The format of 
the file is not readily convertable to random access 
type storage required for a true on-line system. One of 
the major problems is that the MDR master file is inter- 
faced with the rest of the NAILC/MIS programs and therefore 
an MDR file is required in the NAILC/MIS system. The 
present proposal is to duplicate the MDR file on magnetic 
tape each day and load it into the Burroughs 4?00 for 
operation of the on-line file maintenance . 

To meet the user requirements, the MDR master file data 
base has to be altered in one or more of three ways: (1) in 

the format of the file, (2) the content of the file, (3) in 
the storage medium where the file is located. Two logical 
file organization techniques are used for data storage 
and on-line systems. In a sequental file, records are 
physically arranged on the storage media in the same order 
as their logical sequence. File maintenance and search 
operations are particularly inefficient in this type of 
file. Files can be organized by grouping together all 
records which have some common value used as an index 
term; this is called a subfile. An inverted file is 
created by establishing a collection of subfiles consisting 
of all the file partitions that are generated by grouping 
records that have some field value in common. This 



organization requires a dictionary or directory containing 
all the data values in the system and the locations where 
those values occur. The major advantage of an inverted 
file is random access capability; however both the file 
and the directory have to be maintained. An inverted or 
indexed sequential file is proposed for the on-line project. 
This type of file organization provides the advantages 
of inverted files without the disadvantages. 

B. EQUIPMENT 

In order to operate an on-line system effectively the 
user need not even know of the existence of system com- 
ponents other than the terminal he is using and, perhaps, 
an off-line printer. The system is composed of several 
components: the central processing unit (CPU) auxiliary 

storage, communication unit peripheral devices and some 
type of communications medium to link the units together. 

The following paragraphs will briefly describe the 
components of the on-line system (Ref. 4). 

The heart of any computer system or configuration is 
the CPU; all computer configurations perform five basic 
functions: (1) input, (2) primary storage, (3) arithmetic- 

logic, (4) controls, (5) output. The actual CPU is made 
up of the primary storage, arithmetic-logic and control 
functions. The input function makes available to the 
CPU the data to be processed and instructions as to the 
method of processing. The output refers to the results 
of the data processed within the CPU and is written on 
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any one or a combination of various output media. The 
input and output units also translate the data into 
machine language from whatever form it is provided in 
and vice versa. 

The computer system requires controls to perform the 
following functions; 

(1) Tell the input device what data to enter into 
primary storage and when and where to enter it. 

(2) Tell the arithmetic-logic section what operations 
to perform, where the data is and where to place the result 

( 3 ) Tell what file devices to access and what data, 
to access, and 

( 4 ) Tell what output media the results are written on. 
The arithmetic-logic section manipulates tha data in 
accordance with the algorithm of instructions. The manip- 
ulations are performed one operation at a time, with 
intermediat results being placed in primary storage. The 
primary storage is that section of the CPU where data and 
instructions are entered from the input device; results 

of intermediate processing of data are stored here along 
with final results until the computer is directed to 
write the results on output media. 

The stated size of the CPU refers to the capacity of 
the primary storage. The size of a processor's primary 
storage helps to determine the maximum size of programs 
and the maximum amount of data available for processing 
at any one time. Storage capacity is expressed in terms 
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of the number of addressable storage locations within 
the primary storage unit. The byte, made up of eight 
binary digits and a parity digit, is the basic storage 
unit of some computer systems. These bytes can be 
strung together in different ways to provide variable- 
length or fixed-length words . Flexibility results 
from the ability to string together bytes to make half- 
words, words and double words. The Burroughs 4700 com- 
puter system has a primary storage of 500 K (where K 
means thousands); that is, it has 500,000 storage loca- 
tions (bytes) each of which is addressable by a programmer. 
The CPU can also be evaluated by two other aspects: 
access time and cycle time. Access time refers to the 
time it takes for the control section to locate instructions 
and data for processing. The CPU operates on pulses per 
length of time like a clock. During the instruction 
cycle, an instruction is obtained from a primary storage 
location and transferred to the arithmetic-logic section. 
During the execution cycle the instruction is executed 
using date in locations specified by the instruction; then 
the computer shifts back to the instruction cycle. The 
cost of pirmary storage is based on speed; as speed in- 
creases, the cost per bit stored increases. The virtual 
storage technique is a scheme which appears to increase 
the size of the primary storage. The basic idea is the 
dynamic linking of the primary storage with a slower, 
larger auxiliary storage. 
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Magnetic disks are the most popular choice among 
computer vendors and users. Magnetic disks come in 
several sizes and models; some are stationary devices 
and others are in the form of a stack of rotating metal 
discs on a spindle. Each disk surface is divided into 

tracks which are analogous to flattened, circular sec- 

« 

tions of magnetic tape. Read-write heads mounted on 
access arms move in and out of the stack and are positioned 
over a particular track which contains data of interest. 

The speed with which data are written or read is depen- 
dent upon access mechanism movement time, type of 
read-write head, rotation speed of disk pack and the 
density at which the data are recorded. The transfer 
rate of a typical disk pack is 156,000 bytes per second. 
Disk files may be organized sequentially and processed 
like magnetic tape in addition to indexed sequential and 
direct access organization. On-line inquiry capability 
of large files is an example of the flexibility of disks. 

When the total number of terminals and printers 
and the amount of data transmitted exceed a certain level, 
the computer control progran (in residence) can no longer 
execute the interrupts, move the data into and out of 
storage and perform the necessary housekeeping without 
significant reduction in computer throughput. To in- 
crease the capacity of the computer system, these func- 
tions can be moved out of the CPU and into a. communications 
processor of "frontend" processor. Channels from various 
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terminals and other remote devices end at the front-end 
processor, and this processor in turn transmits clean 
data to the host CPU. A front-end processor will 
perform some, if not all, of the following functions 1 . 

(1) Act as a message-switching center, acts as the 
central exchange in a fully interconnected communications 
network between terminals. 

(2) Routine housekeeping duties such as data requests, 
handling of message queries and priorities, etc. 

(3) Error checking and verification. 

(4) Gathering of system statistics. 

(5) Code translation into the machine language of 
the host CPU. 

(6) Preprocessing and editing. 

(7) Routing messages to and from required memory 
locations and notifying the software as required. 

Devices which are used to get the data into the system 
and information from the systems are called terminals. 
Terminals vary from teletypewriters to card readers , 
high-speed printers, CRTs, etc. An intelligent terminal, 
with the aid of a minicomputer, has the capability to 
perform operations on the data it handles in addition to 
transmitting it to the CPU. Minicomputers are physically 
small, relatively inexpensive and have a stored program 
of at least 4K. Minicomputers are used as front-ends 
(as discussed in the preceding paragraph) , general 
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purpose computer systems and as intelligent terminals. 
Rather than use a front-end to the CPU in a computer 
system, intellignet terminals can be sued to extend the 
capacity of the CPU. Also it is feasible for the ter- 
minal to accept transactions and perform some processing 
when the main computer is down or the communications 
system is interrupted. 

CRT terminals are available in an almost countless 
variety of capabilities and prices. Basically, a CRT 
terminal has a keyboard for alphameric data entry and 
a CRT for visual output. The primary internal components 
are a memory and a character generator. The memory allows 
the operator to transmit data by the page or screenful 
rather than character by character. Most CRT terminals 
have optional data entry and editing devices available 
such as a cursor— a spot or other symbol on the face of 
the CRT that indicates the location at which the next 
data entry or reception operation will take place; or a 
light pen—an electronic ballpoint pen that emits a 
stream of electrons and is used to write directly on 
the CRT screen. 

C. IMPLEMENTATION OF THE ON-LINE SYSTEM 

The proposed implementation schedule for the MDR 
on-line project calls for a moduler or pilot approach. 
Initial installation of prototype equipment and training 
of personnel is to begin in September, 1975* The prototype 
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is to be installed in OA-621 and the MDR file for a 
particular aircraft program will be run in parallel 
with the manual system for a period of 30 days. There 
are several advantages to this type of approach, A 
high degree of protection is provided in the event of 
failure of the system. The risk of system failure is 
localized and the problems can be identified and cor- 
rected before further implementation is attempted. This 
approach also provides a live, hands-on environment to 
train operating personnel. 

The implementation scheme is modular in that the 
system is to be introduced in levels of complexity. On- 
line retrieval of MDR records only will be the first 
level. As the on-line retrieval becomes operational 
and perfected, on-line, batch updating of the prototype 
file will begin. The final stage of implementation 
real-time update and retrieval of the entire MDR master 
file. The phase-in approach offers several advantages: 
(1) rate of change can be minimized, (2) the system can 
be implemented over long time period with a minimum 
budget, (3) equipment can be acquired over a longer time 
period-reduced initial capital outlay. A major disadvan 
tage is the development of a demoralizing atmosphere in 
the organization of "never completing a system" (Ref. 4) 
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V. DISCUSSION AND RECOMMENDATIONS 



A. ON-LINE PROJECT 
1. General 

The on-line project being pursued at the NAVAIRE- 
WORKFAC is essentially a conversion from one method of 
data processing to another method of data processing. 

The project is not an attempt to alter the design of the 
system but to computerize a specific activity of the 
system- -MDR master file maintenance. Several problems 
have surfaced during the development of the projects 
the large size of the MDR master file, the size and com- 
plexity of an individual MDR and the need to interface 
the MDR master file with the remainder of the NAILC/MIS 
system. 

The development cycle of a management information 
system needs to contain control systems, well identified 
check points and organization checks and balances in 
order to make efficient use of resources. This cycle 
is broken up into separate phases, the phases serving 
as structural standards, which guide the system develop- 
ment. Table III is a suggested breakdown of the development 
process into six phases. 

The development schedule for the NAVAIREWORKFAC 
On-Line Project, Appendix C, does not include a feasibility 
study. The feasibility study allows management to 
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Phase 


. Title 


I . 


Feasibility Study 


II 


System Specification 


III 


System Engineering 


IV 


Programming and Procedure Development 


V 


Implementations 


VI 


Operation 



Table III. System Development Cycle (Ref. 6 ) 

answer questions in three areas: (1) Is the proposed system 

a solution to the actual problem? (2) Does sufficient 
economic justification exist to allocate resources to the 
project? ( 3 ) How does the project fit into the master 
plan? System projects should be within the context of 
the organization's long-range master that defines the 
general nature of systems that will be developed for some 
extended time period. Each project must be evaluated 
against that master plan, and either modified to be con- 
sistent with it or cause changes to the master plan. 

2. User Requirements 

The user requirements (Appendix B) were compiled 
during interviews and conferences between project per- 
sonnel and users. Several iterations of the process 
were necessary to get the list of requirements to its 
present form which agrees well with a suggested list of 
user requirements for a general on-line system. To 
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completely satisfy the user requirements would nec- 
cessitate implementation of a full on-line retrieval 
and real-time update system. To effectively implement 
such a system would require extensive redesign of the 
present MDR file maintenance process, the MDR master 
file and the concept of the MDR itself. This task is 
beyond the scope of the NAVAIREWORKFAC . 

3 . Proposed System 

The proposed on-line system utilizes CRT type 
terminals with a maximum line length of 80 characters. 

The maximum line length of an MDR record requires a 
line length of 120 characters. In addition only 11 lines 
can be displayed on the CRT at any one time. These re- 
strictions have necessitated extensive redesign of the 
format of the MDR record into eight separate displays. 

This reflects a decision made during the beginning stages 
of the project based on the fact a CRT of large enough 
capacity was not then currently available and that the 
hardware for the system was intended to be purchased 
outright. At the present time, CRTs of large enough 
capacity are available but at a cost greater than twice 
the smaller version. The original intention to buy has 
since been modified to the idea of leasing. 

The proposed system uses 17 CRT Terminals, 16 
for the analysts and one- for display purposes. Calculations 
made using the workload data collected, Table II and 
Appendix A, show that a minimum of 15 CRT terminals will 
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be required to handle the full workload of OA-621. The 
data also show that only four terminals would be suffi- 
cient for a record retrieval only system. The time 
required to complete an MDR update operation was based 
on estimates of individual analysts to complete an update 
operation in the present} manual system. This time figure 
assumed no learning curve for the analysts once the on-line 
system was fully implemented. The time required for a 
file search and retrieval operation was assumed constant 
at one and a half minutes per operation. The sample size 
taken was relatively small and therefore the data is not 
as good as it could be. Comparing the analysts' estimates 
with OA-621 branch records indicate workload and time 
estimates may be underestimated. 

One problem that has not yet been considered to 
any extent by project personnel is that of file security. 

In any information system incorporating a large data base, 
security is an important aspect. One example of a file 
security system taken from a court information system 
incorporates four levels? (1) Each person authorized 
to update the files is assigned an access code. (2) Cer- 
tain terminals are designated as display terminals only. 

(3) Transactions on given terminals are restricted to 
certain files only based on areas of responsibility. 

(4) Transactions for a given terminal are restricted to 
authorized fields and modifications to the file can only 
be made during those periods when authorized persons are 
on duty (Ref. 4). 
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B. RECOMMENDATIONS 



1. Cost Evaluation of On-Line Project 

The on-line project is an investment of resources 
and as such should be justified in terms of a cost- 
effectiveness analysis. Questions that should be 
answered are: (1) assumed operational lifetime of system; 

(2) project development cost; (3) present system operating 
cost; (*f) projected operating cost of new system; and 
(5) operating cost benefits. Certain costs of the sys*tem 
are sunk costs, for example procurement costs of equipment, 
and can be amortized over the lifetime of the system. 

Other costs, such as maintenance and operational costs 
or lease payments, are recurring costs and, as such, effect 
the monthly cash flow of the organization. When comparing 
the costs of new systems against present systems, care 
should be taken to insure that the marginal costs are 
given the proper attention. 

A preliminary MDR system cost comparison was per- 
formed by the on-line project personnel during February, 
1975* The estimated cost savings for the first year 
of full operation of the on-line system were approximately 
$170,000. However, included in this estimate were sunk 
costs of equipment, such as storage bins and OCR type- 
writers, already owned by the NAVAIREWORKFAC which makes 
the estimate arrived at highly questionable. 
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2 . Lease or Buy 



If a system is going to be in operation for more 
than about five years it is generally cheaper to buy 
rather than lease. However, leasing does not require as 
large an initial outlay and does offer the advantage 
of greater flexibility in the choices of equipment. For 
the application being pursued by the NAVAIREWORKFAC, it 
is recommended that leasing be considered for the CRT 
terminals . 

3. "Brand Y" 

The U.S. Navy is proposing to upgrade the DPSCPAC 
computer facilities with the acquisition of a. new computer 
system commonly referred to as "Brand Y." The proposed 
implementation date is currently July, 1976. The pro™ 
posed date for full implementation of the NAVAIREWORKFAC 
On-line system is February-March , 1976. It should be 
ensured that any equipment acquired, any software acquired 
and/or any system modifications made .are compatible with 
"Brand Y." Further, enough flexibility in the on-line 
sustem must be retained to take advantage of whatever 
the new computer can offer. 

4. Study of MDR system 

The present motivation for the MDR on-line project 
is to produce a "better product." That is, to produce 
an MDR file that is as accurate and up to date as possible . 
A study must be made of the MDR and the role it plays in 

overall operation of the NAVAIREWORKFAC to look for 
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justification and benefits of the on-line project, or of 
a completely redesigned system, in terms of overall per- 
formance of the organization. The question to be asked 
is: What can be done to the MDR system to produce a 

more efficient and timely rework cycle for the aircraft 
for which NAVAIREWORKFAC has responsibility? 
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APPENDIX A. DATA 



I. TIME DATA 

Table IV gives the data collected on the elapsed time 
required for MDR change forms to travel from the Methods 
and Standards Division, 63000, to the OCR typist pool in 
OA-621; and the amount of time required in the OCR typist 
pool for MDR change form to be converted to OCR format 
for input to the computer. The elapsed time includes 
only working days. The data was taken from the Methods 
and Standards input to OA-621 during the period from 
20 January 1975 to 7 February 1975* 



Elapsed 

Time 

(Days) 


# of MDR Change 
forms from 
630 to 621 


# of MDR Change 
forms in 
621 OCR pool 


0 


105 


0 


1 


78 


46 


2 


4-0 


93 


3 


51 


27 


4 


19 


92 


5 


1 


32 


6 


1 


4 


7 


8 


0 


8 


2 


8 


9 


0 


0 


10 


0 


0 



Table IV. MDR Flow Time 
the mean (630 to OCR.) = X = 1.54 days 

the variation = s' = 2.81; the standard deviation = s=l . 67 days 
If a normal distribution holds: 
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95$ confiderxt of not exceeding 4.9 days 
99$ confident of not exceeding 6.4 days 
The mean (time in OCR pool) = X = 3 -08 days 
The variation = s = 2.42 
The standard deviation = s=I . 56 days 
If the normal distributions holds: 

95$ confident of not exceeding 6.2 days 
99$ confident of not exceeding 7-8 days 
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Type 

Operation 


Analysts' Estimates 
ave . low high 


X 




% of Workload 




A 


43 


20 


6? 


43 


B 


31 


13 


55 


32 


C 


12 


6 


19 


14 




Time : 


Tor Operation 
(minutes) 




A 


2.1 


.6 


2.6 


2 


B 


7-3 


4 


11 


7-3 


C 

— 1 


12.6 

l 


8 


22 


13 . 4 



Operations Type 

As 1 to 2 line MDR change 

B: 5 lines or greater (1 MDR change form) 

C : new MDR 

Table V. MDR Workload and Time Estimates 

The data in Table V is reduced data gathered during 
interviews with Operations Analysis analysts employed in 
OA-621. The analysts estimated what percentage of their 
workload was made up of the different type MDR operations. 
The estimates for time required for the operations does 
not include research time. The analysts estimated that 
84 percent (mean) of their total work load was comprised 
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of MDR file maintenance operations. The sample size was 
12 percent of the analysts employed hy OA-621. 

The data in Tables II and V can be used to make a 
rough calculation of the minimum number of terminals 
required in the system. The calculations refer to the 
OA-621 Branch only. 

A = number of MDR records updated per hour 

S = number of update operations per hour that is 
within the capacity of one terminal 

C = minimum number of terminals 

t = time required for operation 

t = ( .48) (2) + (. 36 ) (7.3) + ( . 16 ) (13.4) = 5*7 minutes 

S = 6o/5.7^10*5 operations per hour 

C 7 -§- = \H.ta C ^ is- 

For retrieval only, assume retrieval operation takes 
1.5 minutes maximum: 

S - ^Y\.s - 40 operations per hour 
C s ^ ^ ~ = 7 > C terminals 
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APPENDIX B ; ON-LINE USER REQUIREMENTS 



A. GENERAL REQUIREMENTS 

1. Convert the magnetic tape MDR file to a random 
access storage medium. 

2. Provide real-time (response to inquiry within 5 
to 10 seconds with 3° seconds maximum) access and 
update of the file. 

3. Control access to records and changes to certain 
parts of records by requiring authorization codes 
(vertical and horizontal) . 

A-. Maintain cross-references on-line, either as dic- 
tionary type files or extracts from the MDRs. 

When an MDR is updated, automatically update the 
applicable report and/or cross reference files. 

5. Provide for local option programs. Those required 
at North Island include a Manufacturing Program 
adaption of the MDR file, a Quality Characteristics 
List file, and a Pilot Overhaul program. 

6. Output the file on magnetic tape daily to interface 
with other standard applications. This output can 
also become backup for the random access file. 

The daily file dump and a tape with the daily 
transactions will be needed for recovery. 

?. Acquire CRT and printing terminals which will 

handle the record in its present format and will 
allow "rolling" forward and backward to display 
a complete MDR. 

8. Provide special function keys for add, delete, etc. 

9. Reduce record size by reducing unused records. 

(i.e. Non-used 4XX and 5XX lines.) Publish a 
maximum file size based on hardware limits. 

10. Reduce file size by implementing a multi-use MDR. 

11. Provide on-line, real-time access during working 
hours of the prime shift with exceptions as required. 

12. After 3 minutes of display in an update made with 
no action, clear the CRT but retain the display in 
memory to allow a recall with a function key. 
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B. INQUIRY REQUIREMENTS 



1. Special function keys to bring up option programs 
(display, print, edit, etc.) should be labeled as 
such on the keyboard. A key to generate four zeros 
(beginning with either position 1, 5> or 9 of the 
CIN) would facilitate input of CINs. 

2. Accept proper inquiries by Part Number, Operations 
Analyst Code, Operation Code, NUN, and other 
specified MDR fields. Display and print as re- 
quired the MDRCC and CIN of applicable records 

(or print off line where volume prohibits on-line 
reports). Display an MDR shown in any X-Ref dis- 
play by moving cursor to proper MDRCC/CIN and 
pushing one function key. If only one MDRCC/CIN 
is applicable, display it. Retain batch process 
report programs . 

3- Accept inquiries to display either or: 

a. An MDR (MDRCC and CIN) 

b. An MDR and its subordinates 

(NOTE: Indicate that there are subordinate 

or parent MDRs . ) 

c. An MDR and its overflows 

(NOTE: Indicate that there are overflow MDRs.) 

4. Accept request for display by next responsible code 
for double certification by M&S, Ops Analysis or Q.A. 

5* Accept requests on-line for preparation of off-line 
overnight reports. 



C. DISPLAY REQUIREMENTS 

1. Retrieve and display an entire record or as much 
as practical, in its present format, on a CRT 
screen with the capability to print it on a remote 
printer as required. 

(NOTE: Several 80 column formats are enclosed if 

request is not feasible.) 

2. Upon authorized and valid inquiry from a terminal 
by entry of an MDRCC and CIN: 

a. Display the record on a CRT (or multiple terminals 
simultaneously, if called), or 

b. Print the record on the printer, or 
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c. Indicate on either device that there is no 
such record on file. 

3. Print a record at an addressed terminal other than 
the one where the transaction originates, upon 
authority and proper command. 

4. Display or print reports on-line. Cross references 
were mentioned previously. In addition, report 
deleted records to cognizant Operations Analysts. 
Report deleted lines to M&S . Report records in the 
"holding" status to originator after a specified 
period of time. Print changes in alpha negative 
codes, non- capability records, for Code 623 » and 
deletion of such records to 35^ > 523 > 612, and 

620 only. Generate and print kitting lists for 
manufacturing jobs (part of a local option) . Print 
QCLs upon proper request from control center ter- 
minals (another option) . 

5. Upon receipt of proper authorization, display 
assignments of security codes and statistics such 
as records on file, numbers of changes by terminal, 
etc . 

6. Space filled 4XX and 5XX lines need not be displayed. 

7. Retain the last record displayed to allow recall 
with a minimum of input. 

8. Allow retrieval of an MDR and its subordinates or 
overflows. Provide for "rolling" MDRs forward or 
backward by means of a single function key vice 

a keying of a new control group. 



D. UPDATE REQUIREMENTS 

1. Allow editing of a displayed record on a CRT, via 
keyboard input with new data displayed as typed. 

2. Duplicate all the input validations now employed 
in the batch method, but apply them On-Line. 

Indicate errors to the user of the CRT terminal, 
and do not accept invalid input. 

3- Enable editing of a record displayed on the CRT, 

when authority and validity is established. Allow 
one terminal at a time , in a change mode , to locate 
a line, and any character within a line. Write 
input characters over the old record, storing such 
input until a command is given to effect the change. 
At that time, write the new record to the file and 
display it to the user. Accept new records in 
the same way. 
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4. Delete entire MDRs , upon proper authority. Write 
deleted records to a history tape, to be retained 
for one year. 

5. Require multiple authority on certain changes. 

Chain a trailer record of a proposed change until 
the proper authorization is applied. While this 
"holding" record is on the file, indicate its 
presence to terminals which access the parent re- 
cord. Display or print either the parent or the 
"holding" record upon proper command. Accept 
change input to the "holding" record. Upon receipt 
of necessary authorizations, replace the parent 
with the changed record and display it. 

6. Perform mass copy action changes to as many records 
as possible. These changes include those in the 
present system and some new requirements. These 
changes may be validated on-line and updated off- 
line overnight . 

7. Place all changes requiring more than one organiza- 
tional entities input into a "holdup" file until 
all change requirements are met. 

8. Indicate on each line, the time date and source 
of last line change. 

9. Automatically "spread" a field if a character or 
characters are inserted. Indicate as an error if 
the fields spreads to exceed the space allotment. 
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APPENDIX C. ON-LINE PROJECT TENTATIVE PLAN 



I. Designate Representatives from each area 

II. Work out "real world" details with each representative. 

III. Compile and evaluate needs in terms of input, output, 
and hardware . 

IV. Get approval of statement of requirements t>y NARF 
people involved. 

V. Confer with DPSCPAC. 

VI. Prepare problem difinition document and submit it to 
DPSCPAC. Submit any separate hardware requirements 
to appropriate agency. 

VII. Prepare programs and hardware. 

VIII. Test and evaluate system 

IX. Prepare operating procedures 

X. Conduct training. 

XI. Implement. 

TABLE VI. Initial On-Line Project Schedule (Ref. 8) 
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